IAMによるAWS権限管理 – IAMポリシーの記述と評価論理
よく訓練されたアップル信者、都元です。本日は、IAMユーザやロール等に与えられるポリシーについて。
IAMは、AWSの操作に関するIDと権限を管理するためのサービスです。IAMユーザ等を作ることにより、そのIDで「誰が操作を行うのか」というアイデンティティを管理し、ポリシーによって「その主体はその操作を行う権限があるのか」を管理します。
関連エンティティの整理
IAMの世界には、ユーザ・グループ・ポリシー等のエンティティが出てきますので、まずはその関係を整理しましょう。
左の方はそこそこ理解しやすいと思います。ユーザはグループに所属でき、多対多の関係があります。ロールについては別エントリIAMロール徹底理解 〜 AssumeRoleの正体を御覧ください。
各ユーザ・グループ・ロールには、複数の「ポリシー」と呼ばれるものを0個または複数個付与できます。ポリシーというのは1つのJSONドキュメントで、下記のような形式です。
{ "Version": "2012-10-17", "Statement": [...] }
これを見ると分かると思いますが、ポリシーというのは0個または複数個の「ステートメント」から構成されています。もちろん上記の...の部分に記述されるものなので、ステートメントもJSON形式のドキュメントです。
{ "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": [ "arn:aws:s3:::*" ] }
この中身を見てみると、ステートメントはEffect, Action, Resourceで構成されているのが分かると思います。Effectの値はAllowまたはDenyの何れかで、ActionとResourceは複数の指定ができます。
結果として、1つのステートメントは「あるリソースに対する、あるアクションを、許可する(または拒否する)」という表現ができます。
あるアイデンティティ(ユーザやロール)には、最終的に複数のステートメント(ステートメントの集合)が紐づく構造になっていることが分かるでしょう。
評価論理
各ポリシーそれぞれの結果の出し方
あるアイデンティティがリソースXに対してアクションYを実行しようとした際に、まず、そのアイデンティティに付与された全てのポリシーがそれぞれ評価されます。各ポリシーの評価結果は「明示的拒否 (explicit deny)」「許可(allow)」「デフォルト拒否 (default deny)」の何れかとなります。
前述の通り1つのポリシーには複数のステートメントが含まれています。それぞれのステートメントについて評価を行い、許可ステートメントがあるかないか、拒否ステートメントがあるかないか、という2つの真偽値にまで落とし込みます。
許可ステートメントが | |||
---|---|---|---|
ある | ない | ||
拒否ステートメントが | ある | 明示的拒否 | 明示的拒否 |
ない | 許可 | デフォルト拒否 |
結局、拒否ステートメントがある場合、何はともあれ「明示的拒否」となります。明示的な許可の有無は関係ありません。次に、許可ステートメントがある場合は「許可」となります。該当するステートメントが1つも無い場合は「デフォルト拒否」となります。
最終結果の出し方
全てのポリシーを評価した結果、明示的拒否が1つでもあった場合、最終結果は拒否となります。許可がいくつあっても関係ありません。明示的拒否のほうが優位です。
次に、明示的拒否が1つも無かった時、許可が1つでもあれば、最終結果は許可となります。デフォルト拒否はいくつあっても関係ありません。
残ったケースとして、明示的拒否が0個、許可が0個、つまりは全てデフォルト拒否だった場合。これは最終結果は拒否となります。
まとめ
AWSのAPIコールがある毎に、このような評価を行い、操作の可否を判断しているんですね。この評価論理が分かっていないと、ポリシーを書きミスって、セキュリティに問題のあるシステムを作ってしまいかねません。ポリシーを書く場合は必ず理解しておきたいですね。